A transaction (sometimes also referred to as a ‘Unit-Of-Work’ or ‘UOW’) is a set of related operations that must be completed together. All recoverable actions of the related operations must either complete successfully or not at all. This property of a transaction is referred to as ‘atomicity’. In the simplest case, a transaction will access resources connected to a single computer processor. Such a transaction is referred to as a ‘local transaction’. More often, however, a transaction will access resources which are located in several different computer processors, or logical partitions, each maintaining its own transaction log. Such a transaction is referred to as a ‘distributed transaction’. When a distributed transaction ends, the atomicity property of transactions requires that either all of the processors involved commit the transaction or all of them abort the transaction. To achieve this, one of the processors takes on the role of coordinator to ensure the same outcome at all of the parties to the transaction, using a ‘coordination protocol’ that is commonly understood and followed by all the parties involved.
A two-phase commit protocol has been widely adopted as the protocol of choice in the distributed transaction management environment. This protocol guarantees that the work is either successfully completed by all its participants or not performed at all, with any data modifications being either committed together (completed) or rolled back (backed out) together on failure. Another property of a transaction is its durability. This means that once a user has been notified of success, a transaction's outcome must persist, and not be undone, even when there is a system failure. A recovery manager is used to ensure that a system's objects are durable and that the effects of transactions are atomic even when the system crashes.
The recovery manager saves information required for recovery purposes. This recovery can be for the dynamic backout of a transaction, perhaps as a result of a failure after a task updated a recoverable temporary storage queue. Additionally the recovery data can be used for restoring a transaction processing system to a committed state, for example when the system is restarted after system failure. Typically, the recovery file comprises at least one log containing the history of the transactions performed by a transaction processing system. In the event of a system failure, the recovery file can be played back to return the system to its state right before the failure, and to what the transaction log(s) used to check for and undo transactions that were not properly completed before failure.
Also, in the event of a transaction failure, the transaction log can be used to reverse updates that have been carried out by that transaction, by working backwards from the last change before the failure, hence the name ‘dynamic transaction backout’. The backout occurs before any locks on any affected resources are released, which safeguards other tasks from the possibility of using corrupted data, because modified data is not released for use by them (“committed”) until the current task has finished with it. In case the log needs to be replayed later in a system restart, an entry is first made in the log to indicate that that transaction is being backed out. Examples of systems which carry out such transaction logging include transaction systems such as IBM® CICS® Transaction Server or IBM WebSphere® Application Server, as well as database systems such as IBM DB2® or IBM IMS™. (IBM, CICS, WebSphere, DB2 and IMS are trademarks or registered trademarks of International Business Machines Corporation) in the United States, other countries, or both.). The log typically records the information in the order that the activity occurs. Without some management, this would consume an ever increasing amount of resource. So it must be reorganised on a regular basis so as to reduce its size by the recovery manager carrying out a process called ‘keypointing’.
Keypointing comprises writing current committed values of a system's objects to a new portion of the recovery file, together with transaction status entries and intentions lists for transactions that have not been fully resolved. An intentions list for a transaction contains a list of the references and the values of all the objects/resources that are altered by that transaction, as well as information related to the two-phase commit protocol. Once a keypoint has been taken, i.e. information stored through a keypointing procedure, recovery information for irrevocably committed (or backed out) transactions can usually be discarded from the log, sometimes called ‘trimming’ the log. This reduces the file size of the log as well as the number of transactions to be dealt with during recovery.
The rate that old log records are deleted by trimming should ideally match the rate at which new log data is being generated as new work enters the transaction system and makes its own recoverable changes to resources. In a well tuned on-line transaction processing (OLTP) environment, the volume of log data held on the log should remain reasonably constant over time, with an underlying periodic rise and fall in the number of log records held on the log as both the new work and the housekeeping work are performed. This mechanism for log data deletion usually solves the problem of logs continually growing in size over time. However, a long-running UOW can prevent this mechanism from working as until such a UOW has completed, and its log data is no longer required, its data cannot be deleted from the log and all data logged since the first log entry of that UOW must be maintained on the log. Hence, the system will not be able to trim the log after keypointing, and the log will grow and grow in size. Eventually, when a critical threshold of the logging subsystem, the operating system, or the available hardware is exceeded, this will result in a request to write to the log failing for an “out of space” type of condition.